<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!-- saved from url=(0043)http://xml.resource.org/cgi-bin/xml2rfc.cgi -->
<HTML lang="en"><HEAD><META http-equiv="Content-Type" content="text/html; charset=UTF-8"><TITLE>Draft: OInvite Proof-of-Work Verification Extension 1.0 -
			Draft 1</TITLE>
<META http-equiv="Expires" content="Tue, 02 Mar 2010 23:32:25 +0000">

<META name="description" content="OInvite Proof-of-Work Verification Extension 1.0 -
			Draft 1">
<META name="generator" content="xml2rfc v1.34 (http://xml.resource.org/)">
<STYLE type="text/css"><!--
        body {
                font-family: verdana, charcoal, helvetica, arial, sans-serif;
                font-size: small; color: #000; background-color: #FFF;
                margin: 2em;
        }
        h1, h2, h3, h4, h5, h6 {
                font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
                font-weight: bold; font-style: normal;
        }
        h1 { color: #900; background-color: transparent; text-align: right; }
        h3 { color: #333; background-color: transparent; }

        td.RFCbug {
                font-size: x-small; text-decoration: none;
                width: 30px; height: 30px; padding-top: 2px;
                text-align: justify; vertical-align: middle;
                background-color: #000;
        }
        td.RFCbug span.RFC {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: bold; color: #666;
        }
        td.RFCbug span.hotText {
                font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: normal; text-align: center; color: #FFF;
        }

        table.TOCbug { width: 30px; height: 15px; }
        td.TOCbug {
                text-align: center; width: 30px; height: 15px;
                color: #FFF; background-color: #900;
        }
        td.TOCbug a {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
                font-weight: bold; font-size: x-small; text-decoration: none;
                color: #FFF; background-color: transparent;
        }

        td.header {
                font-family: arial, helvetica, sans-serif; font-size: x-small;
                vertical-align: top; width: 33%;
                color: #FFF; background-color: #666;
        }
        td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
        td.author-text { font-size: x-small; }

        /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
        a.info {
                /* This is the key. */
                position: relative;
                z-index: 24;
                text-decoration: none;
        }
        a.info:hover {
                z-index: 25;
                color: #FFF; background-color: #900;
        }
        a.info span { display: none; }
        a.info:hover span.info {
                /* The span will display just on :hover state. */
                display: block;
                position: absolute;
                font-size: smaller;
                top: 2em; left: -5em; width: 15em;
                padding: 2px; border: 1px solid #333;
                color: #900; background-color: #EEE;
                text-align: left;
        }

        a { font-weight: bold; }
        a:link    { color: #900; background-color: transparent; }
        a:visited { color: #633; background-color: transparent; }
        a:active  { color: #633; background-color: transparent; }

        p { margin-left: 2em; margin-right: 2em; }
        p.copyright { font-size: x-small; }
        p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
        table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
        td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }

        ol.text { margin-left: 2em; margin-right: 2em; }
        ul.text { margin-left: 2em; margin-right: 2em; }
        li      { margin-left: 3em; }

        /* RFC-2629 <spanx>s and <artwork>s. */
        em     { font-style: italic; }
        strong { font-weight: bold; }
        dfn    { font-weight: bold; font-style: normal; }
        cite   { font-weight: normal; font-style: normal; }
        tt     { color: #036; }
        tt, pre, pre dfn, pre em, pre cite, pre span {
                font-family: "Courier New", Courier, monospace; font-size: small;
        }
        pre {
                text-align: left; padding: 4px;
                color: #000; background-color: #CCC;
        }
        pre dfn  { color: #900; }
        pre em   { color: #66F; background-color: #FFC; font-weight: normal; }
        pre .key { color: #33C; font-weight: bold; }
        pre .id  { color: #900; }
        pre .str { color: #000; background-color: #CFF; }
        pre .val { color: #066; }
        pre .rep { color: #909; }
        pre .oth { color: #000; background-color: #FCF; }
        pre .err { background-color: #FCC; }

        /* RFC-2629 <texttable>s. */
        table.all, table.full, table.headers, table.none {
                font-size: small; text-align: center; border-width: 2px;
                vertical-align: top; border-collapse: collapse;
        }
        table.all, table.full { border-style: solid; border-color: black; }
        table.headers, table.none { border-style: none; }
        th {
                font-weight: bold; border-color: black;
                border-width: 2px 2px 3px 2px;
        }
        table.all th, table.full th { border-style: solid; }
        table.headers th { border-style: none none solid none; }
        table.none th { border-style: none; }
        table.all td {
                border-style: solid; border-color: #333;
                border-width: 1px 2px;
        }
        table.full td, table.headers td, table.none td { border-style: none; }

        hr { height: 1px; }
        hr.insert {
                width: 80%; border-style: none; border-width: 0;
                color: #CCC; background-color: #CCC;
        }
--></STYLE>
</HEAD><BODY>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<TABLE summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><TBODY><TR><TD><TABLE summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<TBODY><TR><TD class="header">Draft</TD><TD class="header">D. Fuelling</TD></TR>
<TR><TD class="header">&nbsp;</TD><TD class="header">Sappenin Technologies</TD></TR>
<TR><TD class="header">&nbsp;</TD><TD class="header">March 2, 2010</TD></TR>
</TBODY></TABLE></TD></TR></TBODY></TABLE>
<H1><BR>OInvite Proof-of-Work Verification Extension 1.0 -
			Draft 1</H1>

<H3>Abstract</H3>

<P>
				This document specifies an OInvite Verification Extension to
				mitigate the risk of 'Invitation Spam' inherent in any unsolicited
				request to communicate.
			
</P>
<P>
				This extension mandates that in order for an OInvite to pass
				automated verification properly,
				the Request must include a
				'Proof-of-Work' token that is non-trivial
				to create (from a resource
				perspective), yet is trivial to verify.
			
</P>
<P>
				This extension also specifies how potential OInvite recipients can
				advertise their 'required postage' so that Invitors can determine
				whether or not it is worth attempting to make first contact.
				By
				varying the "postage" required for an incoming
				OInvite, network
				operators will be able to control the quantity and quality of
				incoming OInvites coming from random sources.
			
</P><A name="toc"></A><BR><HR>
<H3>Table of Contents</H3>
<P class="toc">
<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor1">1.</A>&nbsp;
Definitions<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor2">1.1.</A>&nbsp;
Requirements Notation<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor3">1.2.</A>&nbsp;
Definitions<BR>
<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor4">2.</A>&nbsp;
Motivations and Background<BR>
<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor5">3.</A>&nbsp;
Verification Extension Protocol<BR>
<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor6">4.</A>&nbsp;
Conformance<BR>
<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#oi-verification-mechanism-pow">5.</A>&nbsp;
OInvite POW Mechanism<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor7">5.1.</A>&nbsp;
POW Tokens<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor8">5.1.1.</A>&nbsp;
POW Token: version<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor9">5.1.2.</A>&nbsp;
POW Token: claimed_value<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor10">5.1.3.</A>&nbsp;
POW Token: creation_date<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor11">5.1.4.</A>&nbsp;
POW Token: inviteeId<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor12">5.1.5.</A>&nbsp;
POW Token: Extension Field<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor16">5.1.6.</A>&nbsp;
POW Token: rand <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor17">5.1.7.</A>&nbsp;
POW Token: counter<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor18">5.1.8.</A>&nbsp;
Example POW Token<BR>
<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor19">6.</A>&nbsp;
Extension Schema<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor20">6.1.</A>&nbsp;
XML Schema Elements<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor21">6.1.1.</A>&nbsp;
Token<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#pow-ev-schema">6.2.</A>&nbsp;
XML Schema<BR>
<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor22">Appendix&nbsp;A.</A>&nbsp;
Non-Normative Examples<BR>
<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#anchor23">Appendix&nbsp;A.1.</A>&nbsp;
Example: OInvite Request<BR>
<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#rfc.references1">7.</A>&nbsp;
References<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#rfc.references1">7.1.</A>&nbsp;
Normative References<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#rfc.references2">7.2.</A>&nbsp;
Informative References<BR>
<A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#rfc.authors">§</A>&nbsp;
Author's Address<BR>
</P>
<BR clear="all">

<A name="anchor1"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.1"></A><H3>1.&nbsp;
Definitions</H3>

<A name="anchor2"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.1.1"></A><H3>1.1.&nbsp;
Requirements Notation</H3>

<P>
					The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
					"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
					this document are to be interpreted as described in
					<A class="info" href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#RFC2119">[RFC2119]<SPAN> (</SPAN><SPAN class="info">Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March&nbsp;1997.</SPAN><SPAN>)</SPAN></A>
					.
				
</P>
<A name="anchor3"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.1.2"></A><H3>1.2.&nbsp;
Definitions</H3>

<P>
					</P>
<BLOCKQUOTE class="text"><DL>
<DT>Proof-of-Work ('POW')</DT>
<DD>
							Proof-of-Work is a system that uses a CPU
							cost-function to
							generate a token. This token can be
							used to prove
							that some amount of
							work was done in order to create the token.
						
</DD>
<DT>POW Token</DT>
<DD> POW tokens are the result of a POW minting function
							and can be transmitted to a service provider as proof that some
							amount of CPU resources were expended to arrive at the token.
							POW
							tokens require a varying amount of CPU
							resources to create
							(determined in this specification by the value advertised by a
							specific Invitee), but always require very little CPU power to
							verify. Because of
							this dyssymmetry, POW tokens can be used used
							as an economic
							measure of the relative value an Invitor places on
							her desire to contact an Invitee.
					 
</DD>
</DL></BLOCKQUOTE><P>
				
</P>
<A name="anchor4"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.2"></A><H3>2.&nbsp;
Motivations and Background</H3>

<P> One of the main purposes of this extension is the prevention
				of
				invitation-spam in communications networks that
				allow participantsto
				"opt-out" of a particular Communications Relationship (CR).
</P>
<P>First, it is useful to note that in these types of
				networks,
				message-spam is generally not an issue because
				message recipients can
				preclude a particular sender from sending
				more messages
				(e.g.,"un-friending" someone on Facebook or
				"un-following" someone
				on
				Twitter).
</P>
<P>Second, it is likewise useful to note that invitation-spam
				is
				equally uncommon today, albeit artificiallly. This is
				because nearly
				all social networks are "invitation closed" in the
				sense
				that it is
				not possible to "friend" somebody on a different social
				network
				(e.g., it is not currently possible to friend somebody on
				Facebook
				using your Twitter account). By being invitation-closed, a
				particular communications network has the ability to control the
				number
				and frequency all friend requests, thus
				eliminating both
				message and invitation spam.
</P>
<P>Conversely, "invitation-open" communications networks
				will suffer
				from invitation-spam because it will be difficult for
				these networks
				to control unsolicited invitation messages coming from
				an unlimited
				number of domains.
</P>
<P>To mitigate this phenomenon, the mechanisms specified in this
				document create a system whereby
				a recipient can specify a "price" in
				CPU cycles that he/she is
				willing to accept in exchange for looking
				at
				a particular OInvite
				Request (i.e., an invitation to begin
				communicating). 
			 
</P>
<P>
				The rationale behind this system is that it will be un-economical
				for a
				spammer to try and send invitation-spam because
				OInvite users
				will be able to dynamically adjust their "prices" in response
				to
				system-dependent events. For example, a user will be able to
				automatically deny invitations below a threshold of his/her
				choosing. And if a user flags a particular inviation value as being
				spammy, this signal can be propogated to the user's social graph and
				used to increse their overall minimum price to price the spammer out
				of existence.  
			 
</P>
<P>
				Finally, unlike the SMTP-based email system, successully fighting
				spam using this extension in the context
				of OInvite does not require
				a POW token
				be minted for every
				communication message. Instead, POW
				tokens are only required
				at the
				point of "first-contact", when one
				user wishes to begin
				communicating with another user.
			 
</P>
<P>
				The net result of using this extension is the creation of a
				market-based system to dynamically price, based upon a myriad of
				supply and demand factors, the cost at which a particular person
				will demand in order to be "invited" into a communications
				relationship.
			 
</P>
<A name="anchor5"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.3"></A><H3>3.&nbsp;
Verification Extension Protocol</H3>

<P>
				In order for a token to be valid, it must satisfy all of the
				requirements below. If a stamp does not satisfy all of the tests
				below, it SHOULD be considered to be invalid. Conversely, if a token
				does satisfies all of the tests below, then it MAY pass verification
				depending on the outcome of other extensions.
				</P>
<OL class="text">
<LI>
						Determine the token's claimed_value, which is the number of
						indicated Most Significant Bits (MSB) the token claims to contain.
						<BR>
<BR>

					
</LI>
<LI>
						Compute the SHA-256 hash of the token, and inspect the hashed
						value to
						determine
						the number of
						most
						significant 0 bits that it has.
						<BR>
<BR>

						For example, the POW Token
						'1:20:20090501:beth@example.com:invitorid=john@example.org:n3kJezowv+9IkBF6:00000000000000098812'
						yields an SHA-256 output of
						'00000f91d51a9c213f9b7420c35c62b5e818c23e', in which the 5 most
						significant hex digits (20 most significant bits) are 0.
						<BR>
<BR>

					
</LI>
<LI>
						If the computed number of MSB's does not match the
						claimed_value,
						then the stamp is not valid, and verification MUST
						fail.
						Otherwise,
						continue verifying the token with the next step.
						<BR>
<BR>

					
</LI>
<LI>
						Inspect the creationDate to
						ensure
						that
						the token was not created
						more than 2 days in the
						future,
						and
						not
						more than 2 days in the past.
						This 4-day window
						provides
						adequate
						padding to account for time and
						zone differences
						among
						servers, and
						equally protects against mass
						minting attacks
						that
						target specific
						dates and/or times in the
						future.
						<BR>
<BR>

					
</LI>
<LI>
						Verify that the
						indicated
						InviteeId to ensure it represents a
						valid
						user on the system.
						<BR>
<BR>

					
</LI>
</OL><P>
			
</P>
<A name="anchor6"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.4"></A><H3>4.&nbsp;
Conformance</H3>

<P>
				OInvite servers may choose to operate this extension mechanism in
				any order
				relative to other verification extension. For example, an
				OInvite server may wish that an Invitee's pre-defined whitelist
				should supercede a POW token check.
			
</P>
<A name="oi-verification-mechanism-pow"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.5"></A><H3>5.&nbsp;
OInvite POW Mechanism</H3>

<A name="anchor7"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.5.1"></A><H3>5.1.&nbsp;
POW Tokens</H3>

<P>POW Tokens are created by calculating an n-bit partial hash
					collision, which ensures that a computationally expensive
					operation
					must be performed in order to create a new token, and
					thus a new
					OInvite. 
</P>
<P>
					The OInvite Token format is a derivative of the
					<A class="info" href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#Hashcash">[Hashcash]<SPAN> (</SPAN><SPAN class="info">Back, A., “Hashcash - A Denial of Service Counter-Measure,” .</SPAN><SPAN>)</SPAN></A>
					protocol, with all OInvite tokens being compatible with the
					Hashcash V1 stamp format, except for the format of the
					'creation_date' field. OInvite
					also uses HashCash
					extension fields to
					include the 'InvitorId' in the token, which prevents re-use of
					OInvite tokens by different Invitors.
				
</P>
<P>
					
</P><P>An OInvite POW token consists of the following
							fields:
							version, claimed_value, creation_date, inviteeId, and a
							Hashcash
							extension field. Each field is described in more detail
							below. 
</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE>[version]:[claimed_value]:[creation_date]:[inviteeId]:[extension]:[rand]:[counter]
</PRE></DIV>
				

<A name="anchor8"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.5.1.1"></A><H3>5.1.1.&nbsp;
POW Token: version</H3>

<P>The 'version' field is always '1', with new versions of
						OInvite
						potentially specifying new POW Token version numbers.
</P>
<A name="anchor9"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.5.1.2"></A><H3>5.1.2.&nbsp;
POW Token: claimed_value</H3>

<P>The 'claimed_value' field indicates the number of bits that
						a
						particular OInvite POW token claims to contain. Higher values
						are
						more expensive to "mint", with the approximate token creation
						time
						doubling for every single increase in a token's claimed
						value.
</P>
<A name="anchor10"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.5.1.3"></A><H3>5.1.3.&nbsp;
POW Token: creation_date</H3>

<P>
						The 'creation_date' field represents the date and time that a
						POW
						token
						was created. OInvite POW creationDates use the same
						dateTime
						format defined in
						<A class="info" href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#oinvite-core">[oinvite‑core]<SPAN> (</SPAN><SPAN class="info">Fuelling, D., “OInvite Core,” 2010.</SPAN><SPAN>)</SPAN></A>
						.
					
</P>
<A name="anchor11"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.5.1.4"></A><H3>5.1.4.&nbsp;
POW Token: inviteeId</H3>

<P>The 'inviteeId' field is the globally unique identifier of
						the
						entity being invited into the communications relationship. 
						
</P>
<A name="anchor12"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.5.1.5"></A><H3>5.1.5.&nbsp;
POW Token: Extension Field</H3>

<P>The POW token extension field allows for additional fields
						that
						can be used in the POW token signature in order to force the
						token
						to depend on additional information not found in the
						default POW
						token fields. 
</P>
<A name="anchor13"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.5.1.5.1"></A><H3>5.1.5.1.&nbsp;
POW Token: Extension Field Format</H3>

<P>
							
</P><P>The POW Token extension field supports name/value
									pairs, and has the following format: 
</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE>[name1[=val1[,val2...]];[name2[=val1[,val2...]]...]]
</PRE></DIV>
						

<P>Note that the value of an extension field can also contain
							the
							equals sign ('='). However, the first equal sign after a
							semi-colon for any name/value pair is considered to be a
							delimiter equal-sign. 
</P>
<A name="anchor14"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.5.1.5.2"></A><H3>5.1.5.2.&nbsp;
POW Token: Extension Field Example</H3>

<P>
							
</P><P>As an example, the following extension field value
									would be interpreted as follows: extension 'name1' has values
									'2' and '3'; extension 'name2' has no values; extension
									'name3'
									has three values 'var1=2', 'var2=3', '2', and 'val'. 
									
</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE>name1=2,3;name2;name3=var1=2,var2=3,2,val
</PRE></DIV>
						

<A name="anchor15"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.5.1.5.3"></A><H3>5.1.5.3.&nbsp;
POW Token: Required Extension Fields</H3>

<P>OInvite POW tokens require an extension field named
							'invitorId'. This additional field is included for two reasons.
							First, if a particular spammer creates a myriad of POW tokens
							for
							a group of users, it will be useful to be able to ban the
							spammer
							based upon a particular sending address (the invitorId).
							Without
							this field included in the POW token, a banned spammer
							would be
							able to re-use his pre-calculated stamps with a
							different
							'invitorId' without having to recompute them. 
</P>
<P> Second, including the 'invitorId' in the POW token collision
							calculation guards against a race condition where an attacker
							might intercept an OInvite before a particular invitee
							(recipient) has encountered it, change the details of the
							OInvite, and utilize a potential invitor's resources without the
							invitor's knowledge.
</P>
<P>Inclusion of the 'invitorId' as a required extension
							value
							prevents the improper use of an intercepted POW token by
							a
							Man-in-the-Middle attacker. 
</P>
<A name="anchor16"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.5.1.6"></A><H3>5.1.6.&nbsp;
POW Token: rand </H3>

<P>
						The 'rand' field is a string of random characters from the
						alphabet [a-zA-Z0-9+/=] that acts as a random salt to guard
						against
						<A class="info" href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#birthday-paradox">[birthday‑paradox]<SPAN> (</SPAN><SPAN class="info">Misc Authors, “Birthday problem - Wikipedia, the free encyclopedia,” 2010.</SPAN><SPAN>)</SPAN></A>
						collisions which can shortcut the
						effectiveness of this
						proof-of-work scheme.
					
</P>
<A name="anchor17"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.5.1.7"></A><H3>5.1.7.&nbsp;
POW Token: counter</H3>

<P> In order to find a unique POW token with the desired number of
						collision bits, the algorithm needs to calculate the hash on
						potentially many different strings. This counter is incremented
						on
						each try in order to provide more opportunities for hash
						collisions. The 'counter' is composed of characters from the
						alphabet [a-zA-Z0-9+/=] (Note that an implementation is not
						required to count sequentially). 
</P>
<A name="anchor18"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.5.1.8"></A><H3>5.1.8.&nbsp;
Example POW Token</H3>

<P>
						
</P><P>The following is an example of an OInvite POW token
								sent from 'john@example.com' to 'beth@example.com' with a
								claimed_value of 20 bits:
</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE>1:20:20090501:beth@example.com:invitorid=john@example.org:n3kJezowv+9IkBF6:00000000000000098812

</PRE></DIV>
					

<A name="anchor19"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.6"></A><H3>6.&nbsp;
Extension Schema</H3>

<P>
				This extension defines additional XML elements and attributes that
				can be used inside of an OInvite Request and Response in order to
				support the functionality demanded by this extension.
			
</P>
<A name="anchor20"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.6.1"></A><H3>6.1.&nbsp;
XML Schema Elements</H3>

<A name="anchor21"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.6.1.1"></A><H3>6.1.1.&nbsp;
Token</H3>

<P>
						A string that specifies a token in the format defined in
						<A class="info" href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#oi-verification-mechanism-pow">Section&nbsp;5<SPAN> (</SPAN><SPAN class="info">OInvite POW Mechanism</SPAN><SPAN>)</SPAN></A>
						. This token is calculated using a derivative of the HashCash idea
						(www.hashcash.org) which relies on the properties of n-bit partial
						hash collisions to ensure a computationally expensive operation
						must be performed in order to create a valid OInvite. This field
						is
						required only if the VerificationType is 'POW', or as otherwise
						specified by an OInvite extension.
					
</P>
<A name="pow-ev-schema"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.6.2"></A><H3>6.2.&nbsp;
XML Schema</H3>

<P>
					
</P><P>
</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE>
  &lt;?xml version="1.0"?&gt;
  &lt;xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.oinvite.net/ve/pow/1.0"
    xmlns="http://www.oinvite.net/ve/pow/1.0" elementFormDefault="qualified"&gt;

    &lt;xs:element name="token" type="xs:string"/&gt;

  &lt;/xs:schema&gt;

</PRE></DIV>
				

<A name="anchor22"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.A"></A><H3>Appendix A.&nbsp;
Non-Normative Examples</H3>

<A name="anchor23"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.A.1"></A><H3>Appendix A.1.&nbsp;
Example: OInvite Request</H3>

<P>
					The following is an example of an OInvite Request:
					
</P><P>Example:
</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE>
 &lt;oirequest xmlns="http://www.oinvite.net/core/1.0"
  	xml:id="tag:foo.com,2005:8.3093"&gt;

    &lt;creationDate&gt;2009-06-01T18:30:02.25Z&lt;/creationDate&gt;
    &lt;invitorId&gt;bob@example.com&lt;/invitorId&gt;
    &lt;fullName&gt;Bob Smith&lt;/fullName&gt;
    &lt;inviteeId&gt;alice@example.net&lt;/inviteeId&gt;
    &lt;requestType&gt;BOTH&lt;/requestType&gt;

    &lt;verificationExtension type="http://www.oinvite.net/ve/pow/1.0"&gt;

    	&lt;pow:token xmlns:pow="http://www.oinvite.net/ve/pow/1.0"&gt;
    	  1:20:20090501:beth@example.com:invitorid=john@example.org
	  :n3kJezowv+9IkBF6:00000000000000098812
        &lt;/pow:token&gt;

    &lt;/verificationExtension&gt;

  &lt;/oirequest&gt;

</PRE></DIV>
				

<A name="rfc.references"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<A name="rfc.section.7"></A><H3>7.&nbsp;
References</H3>

<A name="rfc.references1"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<H3>7.1.&nbsp;Normative References</H3>
<TABLE width="99%" border="0">
<TBODY><TR><TD class="author-text" valign="top"><A name="Hashcash">[Hashcash]</A></TD>
<TD class="author-text">Back, A., “<A href="http://hashcash.org/papers/hashcash.pdf">Hashcash - A Denial of Service Counter-Measure</A>.”</TD></TR>
<TR><TD class="author-text" valign="top"><A name="RFC2119">[RFC2119]</A></TD>
<TD class="author-text"><A href="mailto:sob@harvard.edu">Bradner, S.</A>, “<A href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</A>,” BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997 (<A href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">TXT</A>, <A href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</A>, <A href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</A>).</TD></TR>
<TR><TD class="author-text" valign="top"><A name="oinvite-core">[oinvite-core]</A></TD>
<TD class="author-text">Fuelling, D., “<A href="http://www.oinvite.net/">OInvite Core</A>,” 2010.</TD></TR>
</TBODY></TABLE>

<A name="rfc.references2"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<H3>7.2.&nbsp;Informative References</H3>
<TABLE width="99%" border="0">
<TBODY><TR><TD class="author-text" valign="top"><A name="birthday-paradox">[birthday-paradox]</A></TD>
<TD class="author-text">Misc Authors, “<A href="http://en.wikipedia.org/wiki/Birthday_paradox">Birthday problem - Wikipedia, the free encyclopedia</A>,” 2010.</TD></TR>
</TBODY></TABLE>

<A name="rfc.authors"></A><BR><HR>
<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://xml.resource.org/cgi-bin/xml2rfc.cgi#toc">&nbsp;TOC&nbsp;</A></TD></TR></TBODY></TABLE>
<H3>Author's Address</H3>
<TABLE width="99%" border="0" cellpadding="0" cellspacing="0">
<TBODY><TR><TD class="author-text">&nbsp;</TD>
<TD class="author-text">David Fuelling</TD></TR>
<TR><TD class="author-text">&nbsp;</TD>
<TD class="author-text">Sappenin Technologies, LLC</TD></TR>
<TR><TD class="author-text">&nbsp;</TD>
<TD class="author-text">Salt Lake City, UT  84117</TD></TR>
<TR><TD class="author-text">&nbsp;</TD>
<TD class="author-text">USA</TD></TR>
<TR><TD class="author" align="right">Email:&nbsp;</TD>
<TD class="author-text"><A href="mailto:sappenin@gmail.com">sappenin@gmail.com</A></TD></TR>
<TR><TD class="author" align="right">URI:&nbsp;</TD>
<TD class="author-text"><A href="http://www.oinvite.net/">http://www.oinvite.net</A></TD></TR>
</TBODY></TABLE>


</BODY></HTML>